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ABSTRACT 


Future Earth observing missions will study different as- 
pects and interacting pieces of the Earth’s eco-system. 
Scientists are designing increasingly complex, interdis- 
ciplinary campaigns to exploit the diverse capabilities of 
multiple Earth sensing assets. In addition, spacecraft 
platforms are being configured into clusters, trains, or 
other distributed organizations in order to improve either 
the quality or the coverage of observations. These simul- 
taneous advances in the design of science campaigns and 
in the missions that will provide the sensing resources 
to support them offer new challenges in the coordina- 
tion of data and operations that are not addressed by cur- 
rent practice. For example, the scheduling of scientific 
observations for satellites in low Earth orbit is currently 
conducted independently by each mission operations cen- 
ter. An absence of an information infrastructure to en- 
able the scheduling of coordinated observations involving 
multiple sensors makes it difficult to execute campaigns 
involving multiple assets. This paper proposes a soft- 
ware architecture and describes a prototype system called 
DESOPS (Distributed Earth Science Observation Plan- 
ning and Scheduling) that will address this deficiency. 
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1. INTRODUCTION 


NASA’s Earth Science vision emphasizes the importance 
of establishing a tighter link among Earth Science mod- 
els, data analysis, and observational activities at all rele- 
vant spatial and temporal scales. To enable such a tight 
linkage, there needs to be an associated information in- 
frastructure binding the cycle of observation, on-board 
data handling and computing, transmission to ground, 
storage, data mining and product distribution to support 
activities such as inverse modeling, data assimilation and 


model evaluation. The cyclical nature of the linkage im- 
plies that new observation goals will emerge out of the 
products generated from previous observations. 

Future remote sensing environment will consist of large 
numbers of networked sensors that are frequency-agile 
and capable of multi-scene observations from different 
space vantage points. Data acquired from such plat- 
forms will be merged with those acquired by more tra- 
ditional systematic missions (such as Landsat). Second, 
for the purpose of validation and model robustness, data 
acquired by other observational platforms, including sub- 
orbital measurements using ground-, airborne-, and bal- 
loon sensors, will be merged with data from remote sens- 
ing platforms to form a sensor-web. Furthermore, the fo- 
cus will be on the development of complex compositional 
Earth Science models, wherein focused process models 
combine iteratively to form interactive multi-component 
models that simulate the coupled behavior of two or more 
Earth system components. A complete multi-component 
model of the Earth is considered the holy grail of Earth 
Science research. 

Consequently, Earth scientists will require data from mul- 
tiple sources distributed in space, over significant periods 
of time, with choices available to the users of the data 
with respect to when, where and how these data will be 
acquired. Planning and executing a series of observations 
will benefit from information technology that provides 
an interface and set of automated tools for accessing the 
sensing resources available to meet observation goals, in 
a way analogous to the way that web-based archive data 
retrieval tools such as EOSDIS provide an interface for 
retrieving data that has been acquired in the past. 

This paper provides an overview of a set of capabilities 
for addressing the need for coordination of observations. 
The system is based on a methodology called model- 
based observing. By Model-based observing is meant 
here the process of allocating and scheduling sensing re- 
sources based on the' goal of validating a specific hypoth- 
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esis derived from an Earth science model. Model-based 
observing allows observation scheduling to be campaign- 
driven, , where a campaign is defined as a systematic set 
of activities undertaken to meet a particular science ob- 
jective. Campaign goals require the collection of data on 
several variables, on different observing resources at dif- 
ferent times and potentially at varying locations. 

In the following sections we first present the overall ar- 
chitecture for model-based observing that links the Earth 
Science community to observation resources. Part of the 
architecture forms the set of capabilities for coordinat- 
ing observations, which is the focus of the remainder 
of the paper. These capabilities are organized into a set 
of components of a system, called DESOPS (Distributed 
Earth Science Operations Planning and Scheduling Sys- 
tem). DESOPS solves a constraint optimization problem 
as well as a schedule execution, monitoring and replan- 
ning problem, all of which are discussed here. 


2. ARCHITECTURE FOR MODEL-BASED OB- 
SERVING 


Model-based observing requires coordinating the assign- 
ments of observation tasks among a collection of re- 
mote sensors or sub-orbital platforms such as ground-, 
airborne-, and balloon sensors, possibly configured into 
an organization (e,g, a train or a sensor web) (4). It is 
assumed here that each sensing or satellite resource has 
a distinct, geographically separated, operations team for 
managing the daily activities of each sensor. Using an 
economic metaphor, the interests and objectives of these 
“resource owners” are potentially different from those of 
the consumers; in particular, the users want maximum 
utility of the data received associated with their specific 
science goals, whereas the resource owners have other, 
potentially conflicting goals. In this regard, the operation 
environment for model-based observing offer challenges 
similar to those potentially solved by so-called computa- 
tional grid systems (9), namely the need to provide visi- 
bility and access to a set of resources while maintaining 
the security and autonomy of operations for each. 

A system for coordinating observations provides an 
added layer between the users of sensing resources and 
mission operations planners. Part of this coordination 
layer consists of software tools that allow consumers and 
providers to express requirements for facilitating the suc- 
cessful completion of observation goals. Resource users 
need to specify a set of measurements as well as a utility 
model for the data to be acquired. They need to be able to 
specify constraints on cost and completion time for their 
campaign goals. They need a mechanism to act as a bro- 
ker to identify available resources and dynamically sub- 
mit requests to schedule observations on them. The tool 
should monitor the execution of these requests and adapt 
to uncertainties in the availability of resources during ex- 
ecution, which potentially involves rescheduling observa- 
tions on the same or different resources. Resource owners 
need a flexible means to specify constraints on the utiliza- 
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tion of the resource, as well as a way to continuously sup- 
ply updated statistics on current load and capacity. They 
need a system that will facilitate improved utilization of 
their resource without interrupting normal mission oper- 
ations. 

The overall architecture js displayed in Figure 1. The re- 
mainder of this paper discusses the layer marked DES- 
OPS (Distributed Earth Science Observation Planning 
and Scheduling). 


3. DESOPS ARCHITECTURE 


The set of system components in Figure 1 labeled DES- 
OPS consists of part of the information infrastructure for 
constructing and executing campaign plans involving a 
collection of sensors, and enables more direct contact be- 
tween Earth Scientists and the mission planning process. 
The next sections describe these component capabilities 
in more detail. 


A constellation model consists of a database and set of 
functions for defining the capabilities and dynamics of 
resources available to the user for observation. There are 
five components to a constellation model: 


3.1. Constellation Model 
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1. a description of the capabilities of a collection of 
geophysical sensors ; 

2. a model of time. For the purposes of coordinated 
campaign, time can be viewed as a finite set of to- 
tally ordered values naturally interpreted as the set 
of days in which some observation can be taken or 
some other event of interest happens; 

3. a global notation for data, enabling a user to in- 
quire about satellite imagery over any portion of 
the world by specifying the location of the data 
of interest. Examples of global notation systems 
are the Worldwide Reference System (WRS) (6), or 
latitude-longitude. 

4. a satellite orbit function for determining the set of 
sensor viewing times for a specified region of inter- 
est; and 

5. for each resource, a mission model that describes 
constraints on the process by which tasks on the sen- 
sor are scheduled by the mission that manages it. 

Collectively the constellation model provides a language 
for specifying the requirements for using a collection of 
sensing resources. 


3.2. Graphical User Interface 

Users define and revise campaigns over time through a 
graphical user interface. Users define a campaign to 
consist of a set of measurements ; an (optional) set of ex- 
ogenous events (such as a fire or volcano); and a set of 
constraints , restrictions the way a campaign can be car- 
ried out. Constraints are described more fully below. 

The main screen of the interface is displayed in Figure 2. 
This screen shows a map for specifying regions of inter- 
est for a campaign, a flexible plan (defined in more detail 
below) and a textual representation of a campaign as a hi- 
erarchy of measurements and constraints. The view path 
swaths (defined below) for one of the requested satellites 
has also been computed automatically and is visually dis- 
played. 


3.3. Planner 

The role of the Planner is to build and manage flexible 
plans. First, the planner constructs an initial flexible plan 
based on user inputs. Second, new constraints are added 
by propagating the effects of the initial set of constraints. 
In particular, the planner generates start times for each 
sensor in the domain of each measurement from view 
paths over specified regions of interest during specified 
time windows. A view path is the intersection of a speci- 
fied region of interest with the path followed by a satellite 
over the user-specified time window. In DESOPS, view 
paths are generated by conducting a web search for this 


data from mission web sites. Alternatively, it is possible 
to generate this data directly through the use of simula- 
tors such as STK (Satellite Tool Kit). Converging on a 
flexible plan is an iterative process in which the user is 
allowed to view and revise the inputs to the problem. 


3.4. Request Manager 

An observation request is a specific assignment of a sen- 
sor, a time, and a location to the measurement. A fea- 
sible observation schedule is a sequence of observation 
requests that satisfy the user specified constraints. In 
general, a flexible plan gives rise to a number of feasi- 
ble observation schedules. The Request Manager in- 
crementally executes a feasible observation schedule by 
submitting observation requests to missions. The Re- 
quest Manager also monitors the state of the executing 
plan, and initiates rescheduling activities where neces- 
sary. To carry out these functions the Request Manager 
implements an execution strategy (described in more de- 
tail below) for dealing with uncertainty in the execution 
environment and applies a state- transition model to mon- 
itor the progress of the plan. 


3.5. Plan Database 

The Plan Database stores all the current information 
about every campaign being managed in DESOPS. The 
database is used in all phases of campaign planning and 
execution, and contains 

1. the definitions of all the measurements in the cam- 
paign; 

2. constraint information 

3. a description of the observation requests generated 
and submitted to missions; and 

4. other information used by the DESOPS components 
associated with the state of a campaign. 


4. CAMPAIGN PLANNING AS A CONSTRAINT 
OPTIMIZATION PROBLEM 


DESOPS ’ scheduling problem can be mapped into a con- 
straint optimization problem (COP). A COP consists of 
a set of variables, each associated with a domain of pos- 
sible assignments, and a set of constraints defined over 
the subset of the variables. Associated with each solution 
(complete set of assignments) is an objective function that 
evaluates the quality of each solution. In a Partial Order 
COP (PCOP) the objective function induces a partial or- 
dering of the set of solutions based on quality. In a multi- 
attribute COP, the objective function can be decomposed 
into a collection of criteria that are combined in some 
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Figure 2 . Graphical user interface for defining coordinated campaigns . The blue box represents the location constraint , 
green boxes represent view paths that satisfy that constraint Also shown are an executing flexible campaign plan depicted 
as a network, and a tree representation of the plan objects and constraints . 


manner to obtain the objective function value. In DES- 
OPS, variables are associated with measurements and the 
domains will be triples of times, locations and sensors, 
In this section we formulate the problem and describe the 
approach to generating plans. 


4.1. Campaign Constraint Definition 

The constellation model provides domains of sensors S, 
locations L , and times T, and defines location con- 
straints on S x L x T that restrict possible values for 
measurement variables. Formally, we define a function 
orbs k : GN — > T, where GN is an area on the Earth 
described using some global notation, and orbs k (r) C T 
is a set of viewing times for a specified location r on a 
sensor Sk € S. Each sensor Si € S is associated with a 
cost cost(Si) for using it to take an image. 

Each campaign consists of a set of measurements {Mi}, 
a set {Ek} of exogenous events, and a set of con- 
straints. Each measurement Mi is associated with a tu- 
ple of request variables SMi , Jm*., Zm* , where the domain 
of SMi ( dom(sMi )) is a subset of S, the domain of 
( domifMi )) is a subset of T, and dom(lMi ) is a set of 
locations. Let s var = {sm* : 1 < ^ < n}; define 
t var andl var similarly, and let tnyo t <p — — iyo,T U SyciT L ^vav • 
The user may designate a subset of M to be “optional”, 
meaning informally that if no observation is taken of the 
measurement variable, the campaign will still have value. 


A measurement that is not optional is required. 

An exogenous event Ek can be specified as a pair of pa- 
rameters t s Ek , , of start and end times, with domain T. 

These variables can be viewed as discrete random vari- 
ables with a probability distribution over T. For a given 
campaign M, let vm = TUvar U e par . 

The set Cm of user-specified constraints on a campaign 
M are defined over, and restrict the permitted values of, 
variables in m var . There are six kinds of constraints: 

1. For each Mj e M, there are sensor domain 
constraints of the form dom(sMj) = Sm v <s m .* 
where Sm^ £ S, and <s Mj specifies a preference 
ordering for elements in Sm 6 \ Sk <s Mj S p means 
’’prefer acquiring data with Sk over S p for measure- 
ment Mf\ 

2. A temporal constraint has one of two flavors. The 
first provides a means to coordinate measurements, 
or to constrain start times for measurements, and has 
the form t Xj - t Xi € {T u . . . , Ti +r n},pref, where 
pref € {min, max, mid} is an (optional) pref- 
erence function for times in {Ti, . , . , T i+m }, and 
where Xj € m var U e par . The other flavor of 
temporal constraint restricts the times of measure- 
ments with respect to exogenous events, and has the 
form t Xj - t Xi € {Ti,..., a), where 
p(p, a) specifies a probability distribution over the 


5 


set of times, and where x Xj e m var U e var . Such 
a constraint expresses a prediction about when an 
exogenous event will occur. 

3. A region-of-interest l Mi , and an associated time 
window [T s> T e ], T s ,T e , € T, are specified for each 
measurement M*. A location constraint induced 
by the specified region-of-interest is of the form 
dom(t Mi ) - UsgSm, orb s(lMi ), i.e. the domain of 
tMi is restricted to the set of times for which there is 
a sensor S € Sm * available to take the observation 
of the region-of-interest l Mi 

This core set of constraints can be expanded to include 
a budget constraint , a restriction on the overall cost 
Ecost(Mi}of the campaign, and a cloud cover constraint 
which restricts the amount of acceptable cloud cover as- 
sociated with the image. 

A multi-attribute objective function for evaluating solu- 
tions to the DESOPS COP is constructed from a set of 
user-specified criteria for good solutions. These criteria 
include 


1. World feasible: intuitively, a solution is world fea- 
sible if it satisfies the constraints and is consistent 
with the expected behavior of the exogenous events. 

2. Minimal cost: The cost of a solution is the sum of 
the cost of the sensors used on each measurement. 

3. Temporally preferred: preference for solutions that 
maximize the Overall preferences for times. 

4. Resource preferred: preference for solutions that 
maximize the overall preferences for sensors. 

Given a complete assignment to the variables in m var , the 
value of this assignment with respect to each of these cri- 
teria can be rigorously derived from techniques discussed 
elsewhere, e.g. (3), and (2). 


4.2. Campaign Generation 

The process of converging on an high quality campaign is 
an iterative process performed jointly by the human user, 
the DESOPS planner and request manager. There are 
three main steps in the process. First, a minimal flexible 
plan is constructed. A flexible plan for this problem can 
be represented as an augmented Simple Temporal Net- 
work (STN) (8) consisting of nodes representing events 
or measurements, and directed arcs labeled by constraint 
information. The STN is augmented by a representation 
of. temporal preference, uncontrollable events and asso- 
ciated probabilities associated with the time intervals, as 
defined in (3), (12), and (2) (the augmented STN rep- 
resents a Simple Temporal Problem with Preferences and 
Probabilities). An example is found in Figure 3. The plan 



Figure 3 . A simple Flexible Plan. Each node of the 
network represents a measurement or event. Directed 
arcs depict temporal orderings , labeled with the dura- 
tion between event( s) and measurements( s) The sensors 
are listed with each measurement. 

consists of three measurements and one event. The con- 
straint [40 , 100] represents the belief that event El is ex- 
pected to happen sometime beteen day 40 and day 100 of 
the campaign. The other constraints represent temporal 
ordering constraints; for example, the label between Ml 
and El expresses the constraint that Ml should occur 
between 1 and 30 days before El, with a preference for 
times as close to El as possible. The sensor constraints 
are also attached to each measurement in the plan. As 
illustrated in Figure 2, a flexible plan network is part of 
the visual displays available to the user during campaign 
definition. The same display is used during campaign ex- 
ecution to provide the user with status information about 
the plan. For example, in the figure, the blue nodes indi- 
cate measurements that have been acquired, and the yel- 
low node represents an exogenous event that has yet to 
occur. 

Second, from the initial network, new temporal con- 
straints are added by propagating the effects of initial set 
of temporal orderings. Shortest path algorithms (10) can 
be applied to generate the minimal network , a set of con- 
straints that precisely describe the set of solutions to the 
initial problem. In addition, the set of temporally optimal 
solutions can be derived by techniques discussed in (3). 

Third, request sequences of observations are created to 
submit to the missions. To build a single request se- 
quence, it must be decided 

1. Which Mi to select next (ordering of measure- 
ments); 

2. Which admissible sensor Sj to associate with Mi, 

3. Which admissible time Tk to assign to the observa- 
tion request, based on the selection of (2). 

Specified user preferences guide these decisions, and the 
user is allowed to interactively revise the set of observa- 
tion requests to consider. Specifically, the system gen- 
erates the set of candidate observation requests for each 
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measurement; the user is allowed to delete from this can- 
didate list. 


4.3. Example 

Here, we present a hypothetical campaign based on a 
science goal to test an emissions model predicting the 
aerosols released by wildfires. Data on several measure- 
ment variables must be gathered in order to accomplish 
the analysis. In particular, vegetation type or biomass, 
atmospheric aerosol concentration and burned area are 
needed for the region. Fuel moisture content is a variable 
that also would be useful for the objectives of the science, 
though not a necessity. Sensors that provide products at 
various spatial resolutions relevant to these variables in- 
clude Landsat Enhanced Thematic Mapper+ (ETM-h) or 
Thematic Mapper (TM) can be used for mapping vege- 
tation type. Optimal timing for acquiring Landsat data 
for this purpose would be June or July in the same year 
that the fires burned, when forested land can most eas- 
ily be spectrally distinguished from grassland. For map- 
ping aerosol concentration, images coincident to burning 
must be obtained. Moderate Resolution Imaging Spectro- 
radiometer (MODIS) on the Terra and/or the Aqua satel- 
lites would provide data for this variable. MODIS data 
from either platform could also be used to provide coarse 
spatial resolution burned area after (though not too long 
after) the fires were out. For mapping vegetation moisture 
content, hyperspectral data from EO-1 Hyperion instru- 
ment are relevant. The most useful data for this purpose 
would need to be acquired just preceeding the fire. We 
assume the day the campaign is constructed is Day 0 and 
the campaign window is until Day 122. 

• Constellation Model 

- Locations and times are as defined above 

- Sensors 

S = {ETM + ,TM, Hyperion , MODIS} 

with associated orbit functions orb se s and the 
following cost functions: cost(ETM + ) = 
1500 ,cost(TM) — 500, cost (Hyper ion) = 
2000 ,cost(MODIS) m 1000. 

« Problem Inputs 

- Variables: A set M of measurement variables 
aero , moist , veg representing aerosol concen- 
tration, moisture content, and amount of veg- 
etation in burned area, moist is designated as 
optional. A single exogenous event, fire. 

- Sensor constraints and preferences: 

S veg € {ETM + ,TM}, ETM + Caere TM, 
Smout € {Hyperion}, 

Saero € {MODIS}. 

- Temporal Ordering Constraints: 
tveg Tq E {31, 32, ... . , 92}* 
tfire ~ tveg C {0, 1, . . . , 14} , min , 



Figure 4. Network representation of inputs to the fire 
example 

6 aero b fire C- u > 

tfire “ taero ^ 9 
t S fire tmoist ^ 0, min , 

tfire “ To € (105, 106, . . . , 120}, uniform , 
tfi re — To € {61,62, . . ., 75 }, uniform l . 

Regions- of- interest laeroj^moisti^vegi each 
with time window [0, 122]. 

- Budget constraint: cost(M) < 2000. 

• Flexible Plan for Campaign . The flexible plan 
for the original constraints (before propagation) is 
found in Figure 4. There are nodes for each mea- 
surement type and for the start and end of the fire. 
There is a reference node (representing time 0) and 
directed labeled arcs for each constraint. As is cus- 
tomary, the interpretation of an arc between A and 
B is that the temporal gap B — A is constrained to 
have a value in the set of values displayed on the 
edge label. 

Assume the constellation model generates the 
following set of values: 

orbETM+(lveg) = {3,19,35,51,67,83,99,115}; 
cyrb T u{l V eg) = {5,21,37, 53, 69, 85, 101, 117}; 
orbMODis(laero) = {36, 52, 68, 84, 100, 116}; 

Orb Hyperion Qmoist) ~ {0, 30, 60,90, 120}. 

Then the possible observation times can be repre- 
sented by the following location constraints: 
dom(t veg ) — Orb et M+ aero) C orbj'j^ (r aero ) ~ 

{3, 19, 35, 51, 67, 83,99, 37, 53, 69, 85} 

domtymoist) — Orb Hyperion (f moist ) ~ 

{0,30,60,90,120} 

dorn (tn.ero ) = OrbftAQDI S (T aero) 

{36,52,68,84,100,116}. 

The domain constraints, coupled with the user- 
specified ordering constraints, allow for fur- 
ther domain refinements or new ordering con- 
straints. For example, from t veg — To E 
{31,32, . . . , 92} and the domain constraint above, 
we can derive the new domain constraint by in- 
tersection of the two sets, resulting in t veg E 
{35, 51, 67, 83, 99, 5, 21, 37, 53, 69, 85}. 


1 For simplicity, we represent the fire start and fire end as a range of 
expected values in a uniform distribution. 
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Figure 5. A state transition model for measurements. 
States and possible transitions between them are de- 
picted. 


5. EXECUTING A CAMPAIGN REQUEST SE- 
QUENCE 


Executing a campaign requires formulating requests and 
submitting them to missions, monitoring the progress of 
a campaign over time, and initiating rescheduling actions 
as needed in response to unexpected events. The Re- 
quest Manager’s behavior is constrained by an execution 
strategy on when and how requests for measurements are 
submitted to missions. An execution strategy is part of 
a mission model The mission model informs the Re- 
quest Manager on matters related to which mission is 
most likely to be able to fulfill a request, as well as how 
and when to submit the request. For example, the mission 
model may contain a load profile for each sensor, which 
indicates the percentage of time the sensor has been idle 
during a specified period. The Request Manager may ap- 
ply this information by preferring sensors with a smaller 
load. Second, a mission model contains formatting rules 
for request submssion. Third, a mission model contains 
deadlines for submitting requests based on the mission- 
scheduling process. 

The Request Manager monitors a campaign by imple- 
menting a state transition model , which identifies pos- 
sible states of the overall campaign, the component mea- 
surements defined for the campaign, and, for each mea- 
surement, the state of each associated observation request 
and legal transitions between states. The Request Man- 
ager observes whether enabling conditions for a transition 
are met, and, if they are, records the change in state. The 
state transition model also allows the Request Manager 
to detect when a campaign has failed during execution, 
which triggers a suspension of the campaign and notifi- 
cation to the user for rescheduling purposes. 

Figure 5 shows a state transitions for a measurement. A 
measurement starts in a feasible state. It becomes enabled 
when the temporal preconditions for taking the measure- 
ment are met (for example, an exogenous event happens 
or a dependent measurement has been acquired). It be- 
comes infeasible if the constraints make it impossible for 
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Figure 6. A replanning scenario . The occurrence of El 
at time 69 has made it impossible to schedule an obser- 
vation of M3 that satisfies the constraint between El 
and M3. The user must decide whether to relax the con- 
straints on the plan to restore its feasibility. 


it to be taken; this can happen, for example, if all submis- 
sions of requests for the measurement are rejected. Oth- 
erwise, a measurement is pending if at least one request 
for the measurement has been submitted. If a mission ac- 
cepts the request and the image is acquired, the measure- 
ment enters the terminal node Taken . The user may de- 
cide during execution to use data in an archive to acquire 
the needed data. If so, the Request Manager no longer 
submits requests for the observation to the missions. 


5.1. Replanning 

As the campaign plan executes, missions may fail to ac- 
cept requests or exogenous events may happen, or fail to 
happen, at unexpected times. As a result, a campaign may 
become infeasi ble. If a mission rejects a request and there 
are alternative viewing opportunities, the Request Man- 
ager will automatically resubmit requests. If for any rea- 
son, the set of viewing opportunities for a measurement 
is empty during campaign execution, the human user de- 
cides whether to restore feasibility to the plan or to abort 
it. 

Plans are restored to feasibility by relaxing constraints. 
Figure 6 shows a simple plan that was made infeasible 
during execution. Exogenous event El happened at time 
69, A constraint requires measurement M3, which has 
yet to occur, happen between 1 and 30 days after El. M3 
has two observation opportunities: with sensor S2 at time 
100, or with sensor S3 at time 120. Clearly, both exceed 
the upper bound on the temporal ordering constraint, and 
so this constraint is violated. The user may relax the up- 
per bound of the temporal constraint to make the observa- 
tion opportunities consistent with the plan. Alternatively, 
the user may add additional sensors for M3 that include 
opportunities consistent with the ordering constraint, or 
may decide to acquire M3 data through an archive. 

DESOPS provides the user continuous plan execution 
status. It also provides notification of the need for plan 
repair when the plan becomes infeasible during execu- 
tion. Visual and textual information will be provided by 
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DESOPS’ explanation facility, using a model to map plan 
state information into useful textual or visual advice. 

DESOPS is implemented in C++ and Java. The 
implementation is built upon previous work on the 
AMPS/MOPSS system and the EUROPA constraint- 
based planning system (7). An end-to-end prototype with 
the capabilities described in this paper is currently being 
tested and evaluated. 


6. DISCUSSION 


We view observation scheduling, the core capability of 
DESOPS, is one part of a broader vision for managing 
sensing resources for Earth Science. We view the ulti- 
mate goal of developing automated tools for campaign 
management to be the efficient and effective acquisition 
of data products, not simply the scheduling of sensing re- 
sources. Many sensing resources are not “controllable” in 
the sense that they are designed to continuously acquire 
images. For such a mixed environment of controllable 
and uncontrollable sensors, the overall planning problem 
requires the joint management and scheduling of remote 
sensing as well as data archive services. We are currently 
extending the DESOPS architecture to integrate observa- 
tion scheduling with planning for data analysis as dis- 
cussed in (5), which would lead to an end-to-end planning 
system for generating data products. Such systems could 
also plan for “virtual sensing” activities, as discussed in 
( 11 ). 

Second, we are exploring the integration of Earth Science 
domain models into DESOPS planning. This would en- 
able the system to provide more robust advice to a user 
in formulating campaigns. For example, such models 
could advise users on the detailed selection of promising 
regions-of-interest for developing a fire campaign. Fi- 
nally, we are working on devising a means for providing 
a ’’feedback loop” from the results of data analysis to the 
formulation of new campaign goals for DESOPS. Each 
of these enhancements contribute to the overall vision, as 
described in ( 1), to forge a tighter link between modeling, 
observing, and data analysis. 


7. CONCLUSION 


This paper has described a set of capabilities for building 
and executing sequences of observations for accomplish- 
ing complex campaign goals. Observation requests gen- 
erated from user inputs describing campaign goals and 
constraints are submitted electronically to mission oper- 
ations planners, who then decide whether and how to in- 
corporate the request into future mission schedules. The 
system also supports dynamic replanning in response to 
request rejection or unexpected changes in the observing 
environment. The overall approach to distributed plan- 
ning has the advantage of allowing missions to maintain 
ultimate control over their instruments while at the same 


time allowing Earth scientists more visibility into the re- 
sources available for accomplishing their science objec- 
tives. 
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